Subject: UDP Unicast Scalability Proposal

From: Frank Bordonaro <[email-masked]>
Date: Thu, 11 Apr 1996 15:28:49 -0400 (EDT)

Greetings,

 Attached please find the UDP Unicast Scalability proposal.
It is intended to be part of the DLSw Version 2 document
and share common sections and/or be integrated with the 
Multicast proposal. Paul Brittain will be pulling the two 
proposals together.

Regards,
Frank Bordonaro
cisco Systems, Inc.

=================================================================

Frank Bordonaro   cisco Systems, Inc.                      April 1996

DLSw Unicast Protocol Enhancements

1.0 Overview
2.0 Introduction and Definitions
3.0 Reliable Network Transport Overhead
4.0 UDP Unicast Service
4.1 UDP Header Format
4.2 Network Frame Encapsulation
5.0 Definition of Address Resolution Frames
6.0 Circuit Setup/Teardown Process
6.1 Single Session TCP Connection
7.0 Capabilities Exchange
7.1 UDP Unicast Support Control Vector
7.2 Capabilities Exchange Negative Response
8.0 UDP Unicast Reliability
8.1 Retries
8.2 Sequencing

1.0 Overview

 This paper describes the use of UDP unicast service as a transport for
selected DLSw SSP network traffic. This service will improve the scalability
of DLSw.  This enhancement is designed to be fully backward compatible with
existing  RFC 1795 implementations.  Once completed and approved within the
AIW, it is the intent of the DLSw Scalability group to submit these
enhancements to the IETF in the form of an informational RFC.

2.0 Introduction and Definitions

 Address resolution is the process by which DLSw nodes propagate LAN
broadcast traffic to all partner DLSw nodes. When attempting to discover
the location of an unknown resource, a DLSw node sends an address resolution
packet to each partner node. Non-address resolution packets are classified
as circuit setup packets. Circuit setup packets must be sent via a reliable
transport.

 In addition to the address resolution packets described above, RFC 1795 also
propagates NetBIOS broadcast packets into the transport network.  The NetBIOS
UI frames are sent as LAN broadcast packets and RFC 1795 DLSw nodes propagate
these packets over the network transport connections to each partner. These
NetBIOS UI frames are also classified as address resolution packets.

3.0 Reliable Network Transport Overhead

 As defined in RFC 1795, each DLSw node maintains a reliable connection to
its peer partners.  This reliable connection is currently a TCP connection
but DLSw may support other reliable transports in the future. Each reliable
peer to peer connection guarantees reliable and in order packet delivery.
This is accomplished using acknowledgment and sequencing algorithms
which require CPU, memory, and network bandwidth in direct proportion to
the number transport connections.  Specificly, this overhead includes :

  a. Sender must duplicate each segment for possible retransmission
     which consumes processing power and memory.
  b. Control structure memory and CPU required for connection maintenance.
  c. Network bandwidth and CPU for acknowledgements.

DLSw provides network transport service for SNA and NetBIOS. Address resolution
for SNA and NetBIOS requires propagation of LAN broadcasts to all DLSw nodes. 
These broadcast frames do not require reliable delivery as end stations will 
retry. The peer to peer connection must be maintained even though the connection
may never be used for an SNA or NetBIOS circuit.

4.0 UDP Unicast Service

 UDP is an unreliable IP-based packet delivery service. It does not guarantee
the order of packet delivery. As such, it does not contain much of the overhead
associated with TCP. Address resolution frames will be sent via UDP unicast
service. The DLSw RIG will obtain a well-known UDP port for DLSw. This port
can be shared by the UDP unicast and multicast enhancement features. Only
one UDP well-know port is required. The source port is not meaningful.

4.1 UDP Header Format   (CHECK THIS)

  Byte     Description
   0-1     Source Port
   2-3     Destination Port
   4-5     Length of UDP packet (including UDP header and data)
   6-7     Checksum spanning entire UDP packet (optional)

 Many media encorporate a checksum across the entie packet. if UDP can
leverage an underlying media checksum for data integrity, we can save
the overhead of the UDP checksum. (OPEN ISSUE)

4.2 Network Frame Encapsulation

  ------------------------------------------------------------------------
  | WAN Media Header | IP Header (20) | UDP Header (8) | DLSw SSP Header |
  ------------------------------------------------------------------------

5.0 Definition of Address Resolution Frames

 The following table lists SSP messages classified as address resolution
messages that will be sent via UDP unicast service :

     SSP Message        Retries Recommended
  -----------------------------------------
  CANUREACH_EX                Yes
  ICANREACH_EX                No
  NETBIOS_NQ_EX               Yes
  NETBIOS_NR_EX               No
  NETBIOS_ANQ                 No
  NETBIOS_ANR                 No
  DATAFRAME                   No
  DGRMFRAME                   No

 If a reliable connection to a DLSw partner exists and the local DLSw
node and the partner both support the UDP unicast enhancement (see 
section "7.0 Capabilities Exchange"), then address resolution frames 
must be sent via UDP unicast service. It is left up to the receiver
to handle any violations of this rule. 

6.0 Circuit Setup/Teardown Process

Circuit setup is accomplished in the same manner as described in RFC 1795.
If a reliable peer to peer connection does not exist, the first non-address
resolution packet that requires transmission will cause the reliable connection
to be established.  For example, CANUREACH_cs, ICANREACH_cs, NETBIOS_NQ_cs, 
and NETBIOS_NR_cs are sent over a reliable connection.  All other circuit 
setup and takedown related sequences are now passed over the reliable transport
connection.  Correspondingly, reliable connections are brought down when there 
are no circuits traversing the connection.

The process by which DLSw peers not implementing this enhancement establish
peer connections is defined outside this paper.

6.1 Single Session TCP Connections

 RFC 1795 defines a negotiation protocol for DLSw partners to use either two
unidirectional or one bidirectional TCP connection.  If TCP is to be used as
the peer to peer reliable transport and both peer partners support the UDP
Unicast enhancement, they must endeavor to negotiate for one bi-directional
TCP connection.  If one partner detects that the other partner does not
support the use of one bi-directional TCP connection, that partner will
return a negative capabilities response message. See 'Capabilities
Exchange' section for more details. Negotiation to two unidirectional
TCP connections is only supported for migration purposes when communicating
with DLSw partners that do not implement the UDP unicast enhancement.

7.0 Capabilities Exchange

 A new Capabilities Control Vector will indicate if a DLSw partner supports
the UDP unicast enhancement. Capabilities exchange only occurs after the
reliable connection is established. Therefore, for a sending DLSw peer to
utilize the UDP unicast service, it must know the ip address of it's
peer partners via configuration or other means. This document will not address
how an implementation determines if a disconnected peer is UDP unicast capable.
After a reliable connection is established and capabilities exchange has
occurred, the UDP unicast support control vector is used to explicitly
indicate if the partner can receive UDP unicast packets. The absence of the UDP
unicast support CV indicates the partner does not support this enhancement.

7.1 UDP Unicast Support Control Vector

 This control vector is carried in the Capabilities Exchange Request.  Like all
control vectors in this SSP message, it is an LT structure. If additional
UDP unicast services are required in the future, a new control vector may
be added.

 Byte  Description
   0   Length:  Length of the UDP unicast capabilities control vector
                Value is always 0x03

   1   Type:  0x8D (or next available CV Type in DLSw version 2 document)

   2   Support Value:  0x00 indicates UDP unicast service is not supported
                       0x01 indicates UDP unicast service is supported

7.2 Capabilities Exchange Negative Response

 Add reason 0xXXXX to the list of possible negative responses in the DLSw
Version 2 Specification.

  0xXXXX : Indicates that partner detected support for UDP unicast services,
           but negotiation to a single bi-direction TCP connection is not
           supported.

 As in RFC1795, if a DLSw receives a negative response to its initial 
capabilities message, it should take down its TCP connections with the 
offended partner.

8.0 UDP Unicast Reliability

 Same as Multicast Proposal.

8.1 Retries

 Same as Multicast Proposal.

8.2 Sequencing

 Same as Multicast Proposal.